Debug messages can help during debugging but are less useful in general FME use. Many messages (labeled "BADNEWS") are alarming “errors” that FME has trapped and kept to itself (like an end-of-file message). For this reason, you should not turn this option on permanently.

Also, note that the Log Debug setting persists in the workspace. If you turn that setting on and pass the workspace to another user, it retains the setting and shows debug messages when other users run it!

 If the log window text is too small or not stylish enough, use Tools > FME Options > Appearance > Log Font to change the font size and style.

Exercise

Frank's workspace successfully reads address data and transforms it into a new schema, but Chinese characters in the output render as "???". In the previous exercise, he confirmed that the encoding problem occurs when FME writes the data. Now he needs to dig into the Translation Log to find out why.

In this exercise, you will:

• Filter the Translation Log to isolate warning messages.
• Identify a warning that reveals the cause of the encoding problem.
• Fix the encoding by updating the CSV writer parameters.

1) Open and Run Starting Workspace

• Start FME Workbench (2026.1 or later).
• Open your starting workspace (C:\FMEData\Workspaces\UseDataIntegrationBestPractices\customize-and-filter-the-log.fmw).
• Click Run.

2) Filter Log

Now that the workspace has run, check the Translation Log for errors or warnings. Filtering the log down to warnings only makes it easier to spot relevant messages without scrolling through everything.

• Open the Translation Log, check the messages.
  • You should see zero errors and 13 warnings. 
• Click 13 Warnings.

• Review the warning messages.
  • The first two warnings are about data caching being turned on. You can safely ignore these.
  • The remaining warnings come from the CSV writer. They report that FME could not convert certain text values from UTF-8 to IBM437 encoding. Here is an example:
    
    • CSV writer: The string 'Marisa Marmol,麥毅倫,1001,Lagoon Drive ,Vancouver,British Columbia,V6G4W5,Canada,Safe Software,20250603135542.7336085
    • ' could not be converted from 'UTF-8' to 'IBM437'. Changing your writer encoding to UTF-8 will avoid a potential loss of data
  • This confirms the encoding problem occurs during writing. The writer is set to IBM437 (code page 437), an older encoding that does not support Chinese characters. The log is also suggesting the fix: change the writer encoding to UTF-8.

3) Check Writer Parameters

The log pointed to an encoding mismatch. Confirm it by checking the writer settings directly.

• In the Navigator, expand Training [CSV2] CSV writer.
• Expand Parameters and locate Character Encoding.
  • Character Encoding is currently set to ibm437.
• Double-click Character Encoding: ibm437.

• In the Character Encoding dropdown menu, change it to Unicode 8-bit (utf-8).
  • UTF-8 is the modern standard for text encoding. Unlike IBM437, it supports all Unicode characters, including Chinese.

• Click OK.

4) Check Output

Re-run the workspace and verify that the fix worked.

• Run your worksspace.
• Click the PostalAddress writer feature type and click View Written Data.
• Search for Marmol and check the Owner2 column.
  • The Chinese characters should now display correctly.

• Open the output PostalAddress.csv in Microsoft Excel to double-check end-to-end.
  • Optional: If attending a Safe Software live training, open the file in Open Office Calc instead, or skip this step.

The encoding is fixed, and the Chinese characters appear correctly! Problem solved.